New Star Software Collection/NSS_Collection.iso/3-069 qemm 603/1.ima/QEMM-MAN/APPEND-A.QEM

Text File | 1991-10-07 | 22.9 KB | 449 lines

~Heading~ Appendix A: Troubleshooting

 Using LOADHI without QEMM386.SYS

 You can use LOADHI with another 386 expanded memory manager if you
have Quarterdeck's QRAM. This is not as efficient on an 80386,
80386SX or i486 as QEMM's RAM parameter. LOADHI does require that
you either have QEMM386.SYS or QRAM.SYS.

 Using QEMM-386 on 8088, 8086, or 80286 PCs

 QEMM-386 only operates on an 80386, 80386SX or i486 PC. If your PC
does not have an 80386, Quarterdeck's QRAM program supplies
QEMM-386's LOADHI features, if you have EMS 4 or EEMS expanded
memory or Chips and Technologies Shadow RAM. On PS/2 Model 50 and
60s, QEMM-50/60 also provides many of the same features of
QEMM-386, provided you have the proper extra memory hardware.

 PC does not function after booting with QEMM.

 This may occur when QEMM and another device (or feature) of your
PC are unable to cooperate. This section covers problems when just
having DEVICE=QEMM386.SYS in the CONFIG.SYS file causes the
computer to "lock up".  The next section covers problems with
LOADHI~dash~although the information here may prove to be useful as
well. You may need a Boot Floppy to proceed, so be sure to have one
ready (see Appendix B).

 You must first figure out what the conflict is:

~Item~ If you have the RAM parameter on the QEMM386.SYS line in the
CONFIG.SYS file, remove the RAM parameter and reboot.

 If the PC now functions correctly, then some area between 640K and
1024K is being used by a device but the RAM parameter does not see
the device. It thinks that it can put some high RAM into the same
spot.

~Item~ Check to see if any areas which are in the high RAM area are
currently in use by another device~dash~using QEMM.COM or Manifest
First Meg Overview and QEMM Types displays,

 The most common devices are video or network adapters. Usually
QEMM can see these cards, but if areas that are "Mappable" or
"Rammable" are in locations where an adapter already exists, then
you should use the EXCLUDE parameter on the QEMM386.SYS line to
force QEMM not to use these areas.  If a network adapter has some
RAM between 640K and 1024K that QEMM does not recognize, then that
area should be excluded.

 If removing the RAM option does NOT work, then add "X=0000-FFFF
FRAME=NONE" to the QEMM386.SYS line and reboot.  If this works,
type, QEMM ON, to see if QEMM can enter Virtual 8086 mode at all.

 If you are NOT using the RAM parameter and the computer does not
boot correctly, then there is another conflict. Try adding
parameters which disable automatic features of QEMM-386 such as
NOCOMPAQFEATURES, NOTOPMEMORY, NOROMHOLES, NOFILL, NOVIDEOFILL,
NOXBDA, NOSHADOWRAM, IGNOREA20, NOROM, and NOSORT.

 Normally you would not add all of these at once. In fact, adding
one at a time and removing those that have no effect would be the
most efficient way to isolate a problem.  You should remove any
INCLUDE parameters, and specifically EXCLUDE areas you know may be
in use by other devices.  See Chapter 3, QEMM386.SYS Program for
parameters and examine them to determine if there may be a
conflict. Be sure to remove any extra parameters you try which do
not seem to make any difference.  A good starting point is "NOFILL
NOSORT OFF".  You may find that "IGNOREA20 DMA=64 NOROM" makes a
difference.  If it does, see the descriptions of these items to
determine why these parameters are necessary.  Some parameters may
or may not make sense on your PC.

 If you have a PC with Microchannel Architecture, then the MCA.ADL
file may INCLUDE areas for you which may not be correct. Manifest
uses the same MCA.ADL file, and the System Adapters display can
show you the areas used by the adapters.

 If you still have not determined the conflict, then you should
follow the instructions in Appendix C, to create a "pure
environment" in order to isolate the exact problem which is causing
the trouble.

 PC does not function when using LOADHI

 If your PC locks up" after using DESQview's XDV.COM, DV.COM,
LOADHI.COM or LOADHI.SYS, (and having the RAM option does not cause
trouble), then there is probably a memory conflict between 640K and
1024K (see above), but only when the conflicting memory is used.
It's not always easy to tell which program using LOADHI is causing
the problem, but a patient, systematic approach (using LOADHI with
one program at a time) is the fastest and most reliable method.

 While the most common problem when loading items into high RAM is
that the RAM area being loaded into is actually used by something
else, there are programs which are not capable of being loaded
high.  These programs may require addresses below 640K to work for
example.  As long as there is enough room to load the program (you
can use the /GETSIZE option of LOADHI to be sure) most programs can
be loaded into high memory.  Watch the program's initialization
display to see if it loads successfully.

 If the problem is with DESQview's XDV.COM or DV.COM when running
DESQview, then you can use the "/L" (no quotes) option of XDV.COM
to determine the areas of high RAM which XDV is using to load the
DV.EXE file into.  You can then use the "/X=xxxx-yyyy" option to
XDV.COM to specifically exclude areas which may be a problem.  If
you find an area, then use the EXCLUDE parameter on the QEMM386.SYS
line to keep the area excluded.  The /L and /X options to XDV.COM
can both be used at the same time, and the /X option may be used
more than once if needed.

 Network drivers "lock up" or act unpredictably

 This problem is probably a memory conflict with a memory area
between 640K and 1024K. Token Ring, ARCnet, Proteon, Ethernet, and
some others may not be "seen" by QEMM at boot time, so QEMM may
have placed high RAM into the memory area used by the network card.
Use the methods described previously to isolate the conflicting
area and EXCLUDE it on the QEMM386.SYS line in the CONFIG.SYS file.
You may even find the memory address listed when the network driver
initializes, and most network cards list the addresses they use in
their documentation.

 Graphics programs have corrupted displays

 The most likely cause of a graphics program having its display
appear corrupted or "fuzzy" is that some high RAM has been placed
into an area that the graphics adapter was not using until a
particular program started using it. Removing any INCLUDE
parameters and using the QEMM Analyze display after running the
graphics program should identify the area of conflict. You should
then either EXCLUDE the video area being used (somewhere in the
A000 to CFFF area, but probably not all of it), and/or not use
INCLUDE to put high RAM into as large an area.

 Floppy drive does not work or reports "Drive not ready" when
QEMM-386 is loaded

 There are two reasons why the floppy drive may have trouble when
QEMM-386 is loaded.  The first, and most likely, is that you have
used the ROM parameter with QEMM-386.  The ROM parameter copies
your ROM to RAM and then maps the RAM into the same location where
the ROM is.  The result is that the ROM area is  able to work much
faster since it is now using RAM.  However, some ROMs use "timing
loops" to determine if the floppy drive is ready.  Now that the ROM
area is faster, the timing loop takes less time so the computer
thinks that the drive is malfunctioning.  You can either remove the
ROM parameter or attempt to find the exact location of the floppy
drive code (not easy to do) and use ROM=xxxx-yyyy to map the areas
NOT involved with timing.

 The second reason a floppy drive may not work correctly is that is
uses DMA.  Specifying DMA=64 on the QEMM386.SYS line should correct
this problem.

 Attempting to LOADHI a program reports "Not enough room to load
high"

 When using LOADHI, a program needs its "normal" amount of memory
in high RAM in order to get started.  Many TSRs and device drivers
take much more room to initially load into memory and then reduce
their memory size to only the amount needed to stay resident.  The
/GETSIZE (/GS) parameter can be used with LOADHI to determine if
this is happening. Using the Optimize program automatically keeps
track of the amount of "run time" memory as well as its "resident"
size for all programs in the CONFIG.SYS and AUTOEXEC.BAT files, and
will try to find a way to place as many programs in high RAM as
possible.

 LOADHI fails with an SCSI disk drive controller

 When using SCSI (or other "bus master") devices, the memory
mapping feature of QEMM-386 is not seen by the disk controller; the
"bus master" controller will "talk" to the memory directly. Since
the controller doesn't know that the high RAM is being provided
through memory mapping, and LOADHI is asking to place a program
into memory the drive controller can't "see", LOADHI doesn't work
correctly. This is easily corrected by adding DISKBUF=2 to the
QEMM386.SYS line. This parameter tells QEMM-386 to provide a disk
buffer in "non-mapped" memory for the disk drive to use when it
needs to. Higher numbers result in better disk performance, but
increase the resident size of QEMM-386 below 640K. Also QEMM
supports the Virtual DMA Services (VDS) specification which
addresses this problem. Contact the SCSI maker about getting a
driver that supports VDS.

 QEMM-386 reports "not enough room to load"

 If you have only 1MB of memory on your 80386 and use the RAM
parameter, it is possible that QEMM-386 will not have enough memory
to both load itself and fill in all of the unused high RAM areas.
This is especially true on systems which use some of the extra
memory to map ROM for themselves (Shadow RAM) without using QEMM's
ROM parameter.  Since the Shadow RAM is being used to map high RAM
and possibly ROM, there is not enough extended memory left over for
QEMM-386 to load its own program code! QEMM-386 does not run in
Conventional or high RAM; it actually uses extended memory for the
program code. The solution is to get more memory. In the meantime,
you can use RAM=xxxx-yyyy to place high RAM into a smaller area in
order to leave some memory free for QEMM to use, or you may not be
able to use RAM at all.

 Another reason this could happen is that QEMM-386 is not able to
access the "extra" memory beyond 640K on your PC.  QEMM-386 can
find memory, but some PC manufacturers hide their extra memory or
do not allow it to be extended memory.  Once again, there will not
be enough extended memory for QEMM-386 to load itself into. The ROM
parameter uses memory too, and since the PC may already be
performing a similar function, you should remove it until you get
more memory.

 PC boots but the keyboard does not work

 If the keyboard does not respond to the familiar DOS prompt, then
your PC may use the "A20" line in a non-standard way.  The "A20"
line is used to gain access to memory above 1024K and is thus very
important to QEMM-386.  Use of the UNUSUAL8042 parameter should
correct this problem.

 Using QEMM with Microsoft Windows

 QEMM-386 will work with both Windows/286 2.xx and Windows/386
2.xx.  There are several considerations for each.

 For Windows/286 2.xx, QEMM-386 can provide expanded memory for all
programs using Windows. The Windows/286 SETUP program will NOT
complete if there is a valid DEVICE=QEMM386.SYS line in the
CONFIG.SYS file.  You may simply modify the CONFIG.SYS file
temporarily by placing "REM" (without quotes) in front of the
DEVICE=QEMM386.SYS line.  There is no need to reboot after having
changed the CONFIG.SYS line, since the Windows 2.xx SETUP program
only check to see if a valid line is there, and a line with REM in
front of it is not valid.  The Windows 2.xx SETUP program will then
complete and Windows will be installed.  You should NOT have
Windows 2.xx install its "HIMEM.SYS" driver, since QEMM-386
provides an XMS interface already.  Be sure to remove the "REM"
after the installation.

 Windows/386 2.xx can NOT run with QEMM-386 active.  However, the
"Windows" portion of Windows/386 2.xx CAN be used. This is a
program which comes with Windows/386 2.xx called WIN86.COM.  This
program will NOT run "off-the- shelf" programs in Windows, but will
run any Windows-based programs.  The WIN86.COM program may even be
run inside DESQview.

 If you are running several Windows 2.xx programs, it may be
advantageous to run them inside DESQview.  This way, each Windows
2.xx program gets its own memory area to use and does not have to
share the memory with other Windows 2.xx programs.

 Using LOADHI FILES with Microsoft Windows (strange beeping when
starting Windows)

 Microsoft Windows 2.xx seems to not like having the DOS resource
FILES loaded into high RAM.  If there are fewer than 10 FILES
resources below 640K, then Windows will usually act very strangely
when started, and will never actually start working. You must have
at least FILES=10 in your CONFIG.SYS file, and if you run other
programs in DESQview before using Windows, you may need more before
Windows will start. If the problem persists, try adding 5 more
FILES at a time until it goes away. Once you have determined the
minimum needed for Windows additional room for FILES can use
LOADHI.

 Paradox 386 requires QEMM-386 to be ON

 The current versions of Paradox 386 require that QEMM-386 be in
the ON state. If you are not using expanded memory or the RAM
parameter, then you will need to explicitly include the ON
parameter on the QEMM386.SYS line. Later versions of Paradox 386
may correct this anomaly.

 Program reports a "Packed is file corrupt" message

 Some software packages are delivered in a "packed file" format.
This allows more files to fit on the disk and also helps the
program load faster.  Due to a "bug" in some versions of EXEPACK,
the "unpacking" algorithm does not work if the program is loaded
below 64K (not 640K, 64K) and the "A20" line is enabled. Since use
of the LOADHI programs and other features of QEMM-386 can save a
lot of memory, it is possible that the area where programs are
loaded may begin below 64K. If this happens and the "A20" line is
enabled (as it is on some computers and when DESQview is running)
the "Packed file is corrupt" message may appear. Usually you can
add some DOS resources (BUFFERS is a good start) to use up some
memory, or load another COMMAND.COM to get the starting address
above 64K. Running the program in a slightly smaller DESQview
window will also usually make the message go away when it appears
in DESQview.

 Programs report  "Exception 13"

 Exceptions are unusual or invalid conditions associated with the
execution of a particular instruction of the 80386 processor.  The
80386 recognizes several different classes of exceptions, and
assigns a different number to each class. QEMM-386 has been
designed to capture these 80386 exception vectors and display them.
Exception 13 is the "General Protection Fault" error. Any
privileged instruction or any instruction that references memory
incorrectly can cause an Exception 13.

 In the first case, privileged instructions, the Exception 13 could
indicate that a program has executed a privileged instruction or
I/O reference. This could be a special instruction which is only
allowed in protected mode while the PC is not in protected mode.
If this is the case the "Continue" option of the "Terminate, Reboot
or Continue?" prompt  will tell the 80386 to reorder the ranking of
privileged instructions and the program can continue to execute.
However, this will disable QEMM and any programs that have been
loaded high.

 It is the second case, instructions that reference memory
incorrectly, that are far more common to QEMM-386 (and DESQview
386) users. Here the exception may indicate that the current
program has a "bug" or has gone astray in some way. QEMM-386 has
not necessarily caused the "bug" nor has it necessarily caused the
program to act differently. QEMM-386 is just able to report the
problem.  The program may have overwritten some of its own memory
and may in fact be running wild, writing data all over memory and
executing instructions that don't belong to the program.  At this
point when "Terminate, Reboot or Continue" is displayed, the user
can only "Terminate", and in fact the user may not even be able to
do that.

 The technical description of what happens is that a WORD or DOUBLE
WORD value has been written to or read from the last address of a
segment.  The "bug" in the program is that the value is not written
to the first byte of the next segment, but rather wraps to the
beginning of the current segment.  This is probably not what was
intended and, in fact, is not allowed on an 80386.

 This problem may have existed in the program all along and not
been noticed, or it may be due to the higher addresses now being
used when loading programs into high RAM.  The programmer may have
assumed that the program would never address such high numbers.

 DESQview 386 users have two options they may try to fix the
problem.  First, use Change a Program and try to allocate more
memory to the application.  Second, increase the Protection Level
to 3.  This will not alleviate the source of the Exception 13, but
may allow you to find out sooner what is causing the exception.

 When Exception 13 is seen outside of DESQview, it is usually not
recoverable and often difficult to fix.  If the program you are
running is using 80386 protected mode, then perhaps it does not
support VCPI (Virtual Control Program Interface).  Since QEMM-386
uses Virtual 8086 mode, such applications cannot be run under QEMM
without VCPI.  There is no choice but to reboot without QEMM, and
contact the developer of the application to see if they intend on
providing VCPI support.

 If the program was not written for protected mode, then the
problem is harder to fix.  Write down the information displayed
along with the Exception 13 message.  The data displayed is the
address of the PC when the exception occurred, the contents of the
CPU's registers, and several bytes at the exception location. The
data may be intermixed with the screen display, but it is
locatable.

 If any of the registers or the instruction address is 0000, or
FFFE, or FFFF, then the problem is usually "segment wrap". After
rebooting the computer, use LOADHI with no parameters to get a list
of program addresses, or the Manifest First Meg Programs display to
try and see which program was executing at the time of the
exception. If this program has been loaded into high RAM, then see
if loading it below 640K or in a different location eliminates the
problem. Sometimes loading programs in a different order helps, and
sometimes adding or subtracting one from your BUFFERS will change
the location in memory enough to eliminate the problem.

 Technical users can use the instruction bytes displayed to
determine the exact instruction which caused the exception.  Using
DEBUG and entering the values into memory allows you to
"unassemble" the code and, along with the register values,
understand the exact nature of the exception.  This usually does
not solve the problem, but it does show you that the exception 13
was caused by a genuine fault.  Knowing which program caused the
exception (it may be some resident program rather than the one you
thought was executing) is crucial in solving an exception 13
problem.  If you cannot figure out which program causes the
exception, you may need to create a "pure" environment. See
Appendix C.

 Maximum memory size programs in DESQview

 When using DESQview, many people would like to have the largest
possible program area in which to run their programs.  Indeed,
DESQview allows you to "re-use" the memory are below 640K many
times, so having a large area is very important.  You should be
sure that the parameters (using Change a Program) for "Memory Size
(in K)" is quite large (400K is a good number) and "Maximum Program
Memory Size (in K)" is even larger (800K will work).  This makes
sure that the window will be AT LEAST 400K in size, and then
DESQview will allocate more up to the Maximum specified. (The 800K
is far more than is even possible, so you are sure you get all of
the rest without having to figure it out.) In order to gain the
maximum size of memory, you should be using the XDV.COM program (or
have copied XDV.COM to DV.COM, since DOS will always load a ".COM"
file before loading a ".EXE" file).

 The XDV.COM program puts some of DV.EXE into High RAM. You can
find out how much by adding "/L" (no quotes) to the XDV command
line to get a display of the free areas, their size, and how much
of DV.EXE is placed there. This points out an interesting dilemma:
since LOADHI puts items into high RAM, and XDV puts pieces of
DV.EXE there too, you may actually end up leaving some of DV.EXE in
Conventional memory because LOADHI has used up so much of it. You
can check your free memory before running DESQview (with CHKDSK or
Manifest) and then check the "Total Available Conventional Memory"
using DESQview's Memory Status command. You may want to evaluate
what TSRs you are running before DESQview, perhaps they would be
better run inside DESQview. This can free up memory.

 Using memory in the most efficient way possible

 One of QEMM's greatest features is that you can control the memory
you have better than you ever could before.  Many people want to
make sure that the area between 0K and 640K is as large as
possible.  Using high RAM and the LOADHI programs can go a long way
to make sure that the conventional memory area is as big as
possible.  The OPTIMIZE program can assist in maximizing
conventional memory by analyzing the possible methods of loading
items into high RAM and placing them into the best possible
location.  Using Quarterdeck's Manifest program, you can observe
how much memory is still being used below 640K by looking at the
First Meg Programs display.  The DOS Overview display will show you
if more of DOS is being left below 640K that could be loaded high.
A word of caution:  you can spend a lot of time trying to get an
extra few bytes of memory and not really gain much.  Try to
determine what the memory savings will be before attempting to
spend a lot of time rearranging things. Loading TSRs and device
drivers into high RAM is usually the quickest way to gain useful
amounts of memory. On DOS 2.xx and 3.xx systems, loading BUFFERS
into high RAM is easy and provides a lot of memory savings.

 If you need more high RAM, then try QEMM-386's Analyze feature.
There may be areas of memory between 640K and 1024K that you are
not using. You may also find that a particular adapter which is
using a lot of memory addresses above 640K can either be removed or
moved to a different location to get larger contiguous areas of
high RAM. Having many small areas of High RAM is not as useful as
a few large contiguous areas.

 If you are not using ANY programs which use graphics, or if some
large programs you use do not need graphics, you can use the VIDRAM
program to gain a significant amount of memory from your EGA or VGA
adapter.